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Abstract 


A number of Internet application protocols have a need to provide 
content negotiation for the resources with which they interact [1]. 

A framework for such negotiation is described in [2], part of which 
is a way to describe the range of media features which can be handled 
by the sender, recipient or document transmission format of a 
message. A format for a vocabulary of individual media features and 
procedures for feature registration are presented in [3]. 


This document introduces and describes a syntax that can be used to 
define feature sets which are formed from combinations and relations 
involving individual media features. Such feature sets are used to 
describe the media feature handling capabilities of message senders, 
recipients and file formats. 


An algorithm for feature set matching is also described here. 
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1. Introduction 


A number of Internet application protocols have a need to provide 
content negotiation for the resources with which they interact [1]. 

A framework for such negotiation is described in [2]. A part of this 
framework is a way to describe the range of media features which can 
be handled by the sender, recipient or document transmission format 
of a message. 


Descriptions of media feature capabilities need to be based upon some 
underlying vocabulary of individual media features. A format for 
such a vocabulary and procedures for registering media features 
within this vocabulary are presented in [3]. 


This document defines a syntax that can be used to describe feature 
sets which are formed from combinations and relations involving 
individual media features. Such feature sets are used to describe 
the media handling capabilities of message senders, recipients and 
file formats. 


An algorithm for feature set matching is also described here. 


The feature set syntax is built upon the principle of using feature 
set predicates as "mathematical relations" which define constraints 
on feature handling capabilities. This allows that the same form of 
feature set expression can be used to describe sender, receiver and 
file format capabilities. This has been loosely modelled on the way 
that relational databases use Boolean expresions to describe a set of 
result values, and a syntax that is based upon LDAP search filters. 


1.1 Structure of this document 


The main part of this memo addresses the following main areas: 


Section 2 introduces and references some terms which are used with 
special meaning. 


Section 3 introduces the concept of describing media handling 
capabilities as combinations of possible media features, and the idea 
of using Boolean expressions to express such combinations. 

Section 4 contains a description of a syntax for describing feature 
sets based on the previously-introduced idea of Boolean expressions 


used to describe media feature combinations. 


Section 5 describes an algorithm for feature set matching. 
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Section 6 discusses some additional media feature description and 
processing issues that may be viewed as extensions to the core 
framework. 


Section 7 contains a worked example of feature set matching, and some 
additional explanatory comments spurred by issues arising from 
applying this framework to fascimile transmissions. 


1.2 Document terminology and conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


NOTE: Comments like this provide additional nonessential 
information about the rationale behind this document. Such 
information is not needed for building a conformant 
implementation, but may help those who wish to understand the 
design in greater depth. 


1.3 Discussion of this document 
Discussion of this document should take place on the content 
negotiation and media feature registration mailing list hosted by the 
Internet Mail Consortium (IMC): 
Please send comments regarding this document to: 


ietf-medfreeQimc.org 


To subscribe to this list, send a message with the body ’subscribe’ 
to "ietf-medfree-requestüimc.org". 


To see what has gone on before you subscribed, please see the mailing 
list archive at: 


http://www.imc.org/ietf-medfree/ 
2. Content feature terminology and definitions 
Feature Collection 
is a collection of different media features and associated values. 
This might be viewed as describing a specific rendering of a 
specific instance of a document or resource by a specific 


recipient. 


Feature Set 
is a set of zero, one or more feature collections. 
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33 


NOTE: this term is used slightly differently by earlier work on 
Transparent Content Negotiation in HTTP [4]. 


Feature set predicate 
A function of an arbitrary feature collection value which returns 
a Boolean result. A TRUE result is taken to mean that the 
corresponding feature collection belongs to some set of media 
feature handling capabilities defined by this predicate. 


Other terms used in this memo are defined in [2]. 


Media feature combinations and capabilities 


3.1 Media features 


This memo assumes that individual media feature values are simple 
atomic values: 


o Boolean values. 
o Enumerated values. 


o Text string values (treated as atomic entities, like enumerated 
value tokens). 


o Numeric values (Integer or rational). 


These values all have the property that they can be compared for 
equality ('-2'), and that numeric and ordered enumeration values can 
be compared for less-than and greater-than relationship ('«-', '»-'). 
These basic comparison operations are used as the primitive building 
blocks for more comprehensive capability expressions. 


3.2 Media feature collections and sets 


Any single media feature value can be thought of as just one 
component of a feature collection that describes some instance of a 


resource (e.g. a printed document, a displayed image, etc.). Such a 
feature collection consists of a number of media feature tags (each 
per [3]) and associated feature values. 


A feature set is a set containing a number of feature collections. 
Thus, a feature set can describe a number of different data resource 
instances. These can correspond to different treatments of a single 
data resource (e.g. different resolutions used for printing a given 
document), a number of different data resources subjected to a common 
treatment (e.g. the range of different images that can be rendered on 
a given display), or some combination of these (see examples below). 
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Thus, a description of a feature set can describe the capabilities of 
a data resource or some entity that processes or renders a data 
resource. 


3.3 Media feature set descriptions 


A feature set may be unbounded. For example, in principle, there is 
no limit on the number of different documents that may be output 
using a given printer. But to be practically useful, a feature set 
description must be finite. 


The general approach to describing feature sets is to start from the 
assumption that anything is possible; i.e. the feature set contains 
all possible document instances (feature collections). Then 
constraints are applied that progressively remove document instances 
from this set; e.g. for a monochrome printer, all document instances 
that use colour are removed, or for a document that must be rendered 
at some minimum resolution, all document instances with lesser 


resolutions are removed from the set. The mechanism used to remove 
document instances from the set is the mathematical idea of a 
"relation"; i.e. a Boolean function (a "predicate") that takes a 


feature collection parameter and returns a Boolean value that is TRUE 
if the feature collection describes an acceptable document instance, 
or FALSE if it describes one that is excluded. 


P (C) 
P(C) = TRUE <- : -> P(C) = FALSE 
T---------- lene + This box represents some 
| E | set of feature collections (C) 
| Included : Excluded | that is constrained by the 
| E | predicate P. 


The result of applying a series of such constraints is a smaller set 
of feature collections that represent some media handling capability. 
Where the individual constraints are represented by predicates that 
each describe some media handling capability, the combined effect of 
these constraints is some subset of the individual constraint 
capabilities that can be represented by a predicate that is the 
logical-AND of the individual constraint predicates. 


3.4 Media feature combination scenario 


This section develops some example scenarios, introducing the 
notation that is defined formally in section 4. 
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3.4.1 Data resource options 


The following expression describes a data resource that can be 
displayed either: 

(a) as a 750x500 pixel image using 15 colours, or 

(b) at 150dpi on an A4 page. 


(| (& (pix-x=750) (pix-y=500) (color-15) ) 
(& (dpi>=150) (papersize-iso-A4) ) ) 


3.4.2 Recipient capabilities 


The following expression describes a receiving system that has: 

(a) a screen capable of displaying 640*480 pixels and 16 million 
colours (24 bits per pixel), 800*600 pixels and 64 thousand 
colours (16 bits per pixel) or 1024*768 pixels and 256 colours 
(8 bits per pixel), or 

(b) a printer capable of rendering 300dpi on A4 paper. 


(| (& (| (& (pix-x<=640)  (pix-y«-480) (color<=16777216) ) 
(& (pix-x«-800) (pix-y<=600) (color<=65535) ) 
(& (pix-x«-1024) (pix-y<=768) (color<=256) ) ) 
(ua-media-screen) ) 
(& (dpi=300) 
(ua-media-stationery) (papersize-iso-A4) ) ) 


Note that this expression says nothing about the colour or grey-scale 
capabilities of the printer. In the scheme presented here, it is 
presumed to be unconstrained in this respect (or, more realistically, 
any such constraints are handled out-of-band by anyone sending to 
this recipient). 


3.4.3 Combined options 


The following example describes the range of document representations 
available when the resource described in the first example above is 
sent to the recipient described in the second example. This is the 
result of combining their capability feature sets: 


(| (& (pix-x-750) (pix-y=500) (color-15) ) 
(& (dpi=300) (ua-media=stationery) (papersize-iso-A4) ) ) 


The feature set described by this expression is the intersection of 
the sets described by the previous two capability expressions. 
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3.5 Feature set predicates 


There are many ways of representing a predicate. The ideas in this 
memo were inspired by the programming language Prolog [5], and its 
use of predicates to describe sets of objects. 


For the purpose of media feature descriptions in networked 
application protocols, the format used for LDAP search filters [7,8] 
has been adopted, because it is a good match for the requirements of 
capability identification, and has a very simple structure that is 
easy to parse and process. 


3.5.1 Comparison with directory search filters 


Observe that a feature collection is similar to a directory entry, in 
that it consists of a collection of named values. Further, the 
semantics of the mechanism for selecting feature collections from a 
feature set is in many respects similar to selection of directory 
entries from a directory. 


A feature set predicate used to describe media handling capabilities 
is implicitly applied to some feature collection. Within the 
predicate, members of the feature collection are identified by their 
feature tags, and are compared with known feature values. (Compare 
with the way an LDAP search filter is applied to a directory entry, 
whose members are identified by attribute type names, and compared 
with known attribute values.) 


For example, in: 
(& (dpi>=150) (papersize-iso-A4) ) 


the tokens 'dpi' and 'papersize' are feature tags, and '150' and ’ 
iso-A4' are feature values. (In a corresponding LDAP search filter, 
they would be directory entry attribute types and attribute values.) 


Differences between directory selection (per [7]) and feature set 
selection are: 


o Directory selection provides substring-, approximate- and 
extensible- matching for attribute values. Such matching is 
not provided for feature set selection. 


o Directory selection may be based on the presence of an 
attribute without regard to its value. Within the semantic 
framework described by this document, Boolean-valued feature 
tests can be used to provide a similar effect. 
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o Directory selection provides for matching rules that test for 
the presence or absence of a named attribute type. 


o Directory selection provides for matching rules which are 
dependent upon the declared data type of an attribute value. 


o Feature selection provides for the association of a quality 
value with a feature predicate as a way of ranking the selected 
value collections. 


Within the semantic framework described by this document, Boolean- 
valued feature tests can be used where presence tests would be used 
in a directory search filter. 


The idea of extensible matching and matching rules dependent upon 
data types are facets of a problem not addressed by this memo, but 
which do not necessarily affect the feature selection syntax. An 
aspect that might bear on the syntax would be specification of an 
explicit matching rule as part of a selection expression. 


3.6 Describing preferences 


A convenient way to describe preferences is by numeric "quality 
values". 


It has been suggested that numeric quality values are potentially 
misleading if used as more than just a way of ranking options. For 
the purposes of this memo, ranking of options is sufficient. 


Numeric quality values in the range 0 to 1, with up to 3 fractional 
digits, are used to rank feature sets according to preference. 
Higher values are preferred over lower values, and equal values are 
presumed to be equally preferred. Beyond this, the actual number 
used has no significance defined here.  Arithmetic operations on 
quality values are likely to produce unpredictable results unless 
appropriate semantics have been defined for the context where such 
operations are used. 


In the absence of any explicitly applied quality value, a value of 
"1" is assumed. 


Using the notation defined later, a quality value may be attached to 
any feature set predicate sub-expression: 


(| (& (pix-x=750) (pix-y=500) (color=15) );q=0. 
(& (dpi>=150) (papersize-iso-A4) ) ;q-0 
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Section 3.7 below explains that quality values attached to 
sub-expressions are not always useful. 


NOTE: the syntax for quality values used here taken from 
that defined for HTTP 'Accept:' headers in RFC 2068 [9], 
section 3.9. However, the use of quality values defined 
here does not go as far as that defined in RFC 2068. 


3.7 Combining preferences 
The general problem of describing and combining preferences among 


feature sets is very much more complex than simply describing 
allowable feature sets. For example, given two feature sets: 


(& (al);q=0.8 (b1);q=0.7 ) 
(& (a2);q=0.5 (b2);q=0.9 ) 
where: 


feature al is preferred over a2 
feature b2 is preferred over bl 


Which of these feature sets is preferred? In the absence of 
additional information or assumptions, there is no generally 
satisfactory answer to this. 


The proposed resolution of this issue is simply to say that no rules 
are provided for combining preference information. Applied to the 
above example, any preference information about (al) in relation to 
(a2), or (bl) in relation to (b2) is not presumed to convey 
information about preference of (& (al) (b1) ) in relation to (& (a2) 
(b2) ). 


In practical terms, this restricts the application of preference 
information to top-level predicate clauses. A top-level clause 
completely defines an allowable feature set; clauses combined by 
logical-AND operators cannot be top-level clauses (see canonical 
format for feature set predicates, described later). 


NOTE: This memo does not apply specific meaning to quality values 
or rules for combining them. Application of such meanings and 
rules is not prohibited, but is seen as an area for continuing 
research and experimentation. 


An example of a design that uses extended quality value semantics 
and combining operations is "Transparent Content Negotiation in 
HTTP" [4]. Other work that also extends quality values is the 
content negotiation algorithm in the Apache HTTP server [14]. 
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4. 


Feature set representation 


The foregoing sections have described a framework for defining 
feature sets with predicates applied to feature collections. This 
section presents a concrete representation for feature set 
predicates. 


4.1 Textual representation of predicates 


The text representation of a feature set is based on RFC 2254 "The 
String Representation of LDAP Search Filters" [8], excluding those 
elements not relevant to feature set selection (discussed above), and 
adding elements specific to feature set selection (e.g. options to 
associate quality values with predicates). 


The format of a feature predicate is defined by the production for 
"filter" in the following, using the syntax notation and core rules 
of RFC 2234 [10]: 


filter = "(" filtercomp ")" *( ";" parameter ) 
parameter = "q" "=" qvalue 
/  ext-param "=" ext-value 
qvalue = ( "0" E "." O*3DIGIT ] ) 
/ ( "q" [ wow 0*3 ("0") ] ) 
ext-param = ALPHA *( ALPHA / DIGIT / "-" ) 
ext-value = <parameter value, according to the named parameter» 
filtercomp = and / or / not / item 
and = "&" filterlist 
or = "|" filterlist 
not = "I" filter 
filterlist = 1*filter 
item = simple / set / ext-pred 
set = attr "=" "[" setentry *( "," setentry ) "]" 
setentry = value "/" range 
range = value ".." value 
simple = attr filtertype value 
filtertype = equal / greater / less 
equal = wow 
greater = á ">=" 
less = "<=" 
attr = ftag 
value = fvalue 
ftag = <Feature tag, as defined in RFC 2506 [3]> 
fvalue = Boolean / number / token / string 
Boolean = "TRUE" / "FALSE" 
number = integer / rational 
integer = [ "+" / "-" ] 1*DIGIT 
rational = [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT 


Klyne Standards Track [Page 11] 


RFC 2533 A Syntax for Describing Media Feature Sets March 1999 


token = ALPHA *( ALPHA / DIGIT / "-" ) 
string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 


; quoted string of SP and VCHAR without DQUOTE 
«Extension constraint predicate, not defined here» 


ext-pred 


(Subject to constraints imposed by the protocol that carries a 
feature predicate, whitespace characters may appear between any pair 
of syntax elements or literals that appear on the right hand side of 
these productions.) 


As described, the syntax permits parameters (including quality 
values) to be attached to any "filter" value in the predicate (not 


just top-level values). Only top-level quality values are 
recognized. If no explicit quality value is given, a value of ’1.0’ 
is applied. 


NOTE: The flexible approach to quality values and other parameter 
values in this syntax has been adopted for two reasons: (a) to 
make it easy to combine separately constructed feature predicates, 
and (b) to provide an extensible tagging mechanism for possible 
future use (for example, to incorporate a conceivable requirement 
to explicitly specify a matching rule). 


4.2 Interpretation of feature predicate syntax 


A feature set predicate is described by the syntax production for ’ 
filter'. 


4.2.1 Filter syntax 
A 'filter' is defined as either a simple feature comparison ('item', 
see below) or a composite filter ('and', 'or', 'not'), decorated with 


optional parameter values (including "q=qvalue"). 


A composite filter is a logical combination of one or more 'filter' 


values: 

(& £1 f2 ... fn) is the logical-AND of the filter values 'fl1', 
'f2' up to 'fn'. That is, it is satisfied by 
any feature collection that satisfies all of 
the predicates represented by those filters. 

(| fl £2 ... fn.) is the logical-OR of the filter values 'f1', 


'f2' up to 'fn'. That is, it is satisfied by 
any feature collection that satisfies at least 
one of the predicates represented by those 
filters. 
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(! £1) is the logical negation of the filter value 
‘fl’. That is, it is satusfied by any feature 
collection that does NOT satisfy the predicate 
represented by 'f1'. 


4.2.2 Feature comparison 


A feature comparison is defined by the 'simple' option of the syntax 
production for 'item'. There are three basic forms: 


(ftag-value) compares the feature named 'ftag' (in some 
feature collection that is being tested) with 
the supplied 'value', and matches if they are 
equal. This can be used with any type of 
feaure value (numeric, Boolean, token or 
string). 


(ftag<=value) compares the numeric feature named 'ftag' with 
the supplied 'value', and matches if the 
feature is less than or equal to 'value'. 


(ftag»-value) compares the numeric feature named 'ftag' with 
the supplied 'value', and matches if the 
feature is greater than or equal to 'value'. 


Less-than and greater-than tests may be performed with feature values 
that are not numeric but, in general, they amount to equality tests 
as there is no ordering relation on non-numeric values defined by 
this specification. Specific applications may define such ordering 
relations on specific feature tags, but such definitions are beyond 
the scope of (and not required for conformance to) this 
Specification. 


4.2.3 Feature tags 


Feature tags conform to the syntax given in "Media Feature Tag 
Registration Procedure" [3]. Feature tags used to describe 
capabilities should be registered using the procedures described in 
that memo. Unregistered feature tags should be allocated in the "URI 
tree", as discussed in the media feature registration procedures memo 
[34.4 


If an unrecognized feature tag is encountered in the course of 
feature set predicate processing, it should be still be processed as 
a legitimate feature tag. The feature set matching rules are 
designed to allow new feature tags to be introduced without affecting 
the validity of existing capability assertions. 
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4.2.4 Feature values 
A feature may have a number, Boolean, token or string value. 


4.2.4.1 Boolean values 


A Boolean is simply a token with two predefined values: "TRUE" and 
"FALSE". (Upper- or lower- case letters may be used in any 
combination.) 


4.2.4.2 Numeric values 


A numeric value is either a decimal integer, optionally preceded by a 
"+" or "-" sign, or rational number. 


A rational number is expressed as "n/m", optionally preceded by a "+" 
or "-" sign. The "n" and "m" are unsigned decimal integers, and the 
value represented by "n/m" is "n" divided by "m". Thus, the 
following are all valid representations of the number 1.5: 


3/2 
+15/10 
600/400 


Thus, several rational number forms may express the same value. A 
canonical form of rational number is obtained by finding the highest 


common factor of "n" and "m", and dividing both "n" and "m" by that 
value. 


A simple integer value may be used anywhere in place of a rational 
number. Thus, we have: 


+5 is equivalent to +5/1 or +50/10, etc. 
-2 is equivalent to -2/1 or -4/2, etc. 


Any sign in a rational number must precede the entire number, so the 
following are not valid rational numbers: 


3/42, 15/-10 (**NOT VALID**) 
4.2.4.3 Token values 
A token value is any sequence of letters, digits and '-' characters 


that conforms to the syntax for 'token' given above. It is a name 
that stands for some (unspecified) value. 
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4.2.4.4 String values 


A string value is any sequence of characters enclosed in double 
quotes that conform to the syntax for 'string' given above. 


The semantics of string defined by this memo are the same as those 
for a token value. But a string allows a far greater variety of 
internal formats, and specific applications may choose to interpret 
the content in ways that go beyond those given here. Where such 
interpretation is possible, the allowed string formats and the 
corresponding interpretations should be indicated in the media 
feature registration (per RFC 2506 [3]). 


4.2.5 Notational conveniences 


The 'set' option of the syntax production for 'item' is simply a 
shorthand notation for some common situations that can be expressed 
using 'simple' constructs.  Occurrences of 'set' items can eliminated 
by applying the following identities: 


T= [ El, E2, En ] --» (| (T2[E1]) (T=[E2]) ... (T=[En]) ) 
(T=[R1..R2]) --» (& (T>=R1) (T<=R2) ) 
(T=[E] ) cc» LETSE 

Examples: 


The expression: 

( paper-size=[A4,B4] ) 
can be used to express a capability to print documents on either A4 
or B4 sized paper. 


The expression: 

( width=[4..17/2] ) 
might be used to express a capability to print documents that are 
anywhere between 4 and 8.5 inches wide. 


The set construct is designed so that enumerated values and ranges 
can be combined in a single expression, e.g.: 
( width=[3,4,6..17/2] ) 
4.3 Feature set definition example 
The following is an example of a feature predicate that describes a 
number of image size and resolution combinations, presuming the 
registration and use of 'Pix-x', 'Pix-y', 'Res-x' and 'Res-y' feature 


tags: 


(| (& (Pix-x-1024) 
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(Pix-y=768) 
(| (& (Res-x=150) (Res-y-150) ) 
(& (Res-x-150) (Res-y=300) ) 
(& (Res-x-300) (Res-y=300) ) 
(& (Res-x-300) (Res-y=600) ) 
(& (Res-x-600) (Res-y=600) ) ) ) 
(& (Pix-x-800) 
(Pix-y=600) 
(| (& (Res-x-150) (Res-y-150) ) 
(& (Res-x-150) (Res-y=300) ) 
(& (Res-x-300) (Res-y=300) ) 
(& (Res-x-300) (Res-y=600) ) 
(& (Res-x-600) (Res-y-600) ) ) ) ;q-0.9 
(& (Pix-x=640) 
(Pix-y-480) 
(| (& (Res-x-150) (Res-y-150) ) 
(& (Res-x-150) (Res-y=300) ) 
(& (Res-x-300) (Res-y=300) ) 
(& (Res-x-300) (Res-y=600) ) 
(& (Res-x-600) (Res-y-600) ) ) ) ;q-0.8 ) 


5. Matching feature sets 


This section presents a procedure for combining feature sets to 
determine the common feature collections to which they refer, if 
there are any. Making a selection from the possible feature 
collections (based on q-values or otherwise) is not covered here. 


Matching a feature set to some given feature collection is 
essentially very straightforward: the feature set predicate is 
simply evaluated for the given feature collection, and the result 
(TRUE or FALSE) indicates whether the feature collection matches the 
capabilities, and the associated quality value can be used for 
selecting among alternative feature collections. 


Matching a feature set to some other feature set is less 
straightforward. Here, the problem is to determine whether or not 
there is at least one feature collection that matches both feature 
sets (e.g. is there an overlap between the feature capabilities of a 
given file format and the feature capabilities of a given recipient?) 


This feature set matching is accomplished by logical manipulation of 
the predicate expressions as described in the following sub-sections. 


For this procedure to work reliably, the predicates must be reduced 


to a canonical form. The canonical form used here is "disjunctive 
normal form". A syntax for disjunctive normal form is: 
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filter = orlist 

orlist = "(" "|" andlist ")" / term 

andlist = "(" "&" termlist ")" / term 

termlist = 1*term 

term = "(" "I" simple ")" / simple 
where "simple" is as described previously in section 4.1. Thus, the 
canonicalized form has at most three levels: an outermost Ns sj 
disjunction of "(&...)" conjunctions of possibly negated feature 


value tests. 


Klyne 


NOTE: The usual canonical form for predicate expressions is 
"clausal form". Procedures for converting general predicate 
expressions are given in [5] (section 10.2), [11] (section 2.13) 


and [12] (section 5.3.2). 


"Clausal form" for a predicate is similar to "conjunctive normal 
form" for a proposition, being a conjunction (logical AND) of 


disjunctions (logical ORs). The related form used here, better 
suited to feature set matching, is "disjunctive normal form", 
which is a logical disjunction (OR) of conjunctions (ANDs). In 


this form, the aim of feature set matching is to show that at 
least one of the disjunctions can be satisfied by some feature 
collection. 


Is this consideration of canonical forms really required? After 
all, the feature predicates are just Boolean expressions, aren't 
they? Well, no: a feature predicate is a Boolean expression 
containing primitive feature value tests (comparisons), 
represented by 'item' in the feature predicate syntax. If these 
tests could all be assumed to be independently TRUE or FALSE, then 
each could be regarded as an atomic proposition, and the whole 
predicate could be dealt with according to the (relatively simple) 
rules of Propositional Calculus. 


But, in general, the same feature tag may appear in more than one 
predicate 'item'/, so the tests cannot be regarded as independent. 
Indeed, interdependence is needed in any meaningful application of 
feature set matching, and it is important to capture these 
dependencies (e.g. does the set of resolutions that a sender can 
supply overlap the set of resolutions that a recipient can 
handle?). Thus, we have to deal with elements of the Predicate 
Calculus, with some additional rules for algebraic manipulation. 


A description of both the Propositional and Predicate calculi can 
be found in [12]. 
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We aim to show that these additional rules are more unfamiliar 
than complicated. The construction and use of feature predicates 
actually avoids some of the complexity of dealing with fully- 
generalized Predicate Calculus. 


5.1 Feature set matching strategy 
The overall strategy for matching feature sets, expanded below, is: 
1. Formulate the feature set match hypothesis. 
2. Replace "set" expressions with equivalent comparisons. 


3. Move logical negations "inwards", so that they are all applied 
directly to feature comparisons. 


4. Eliminate logical negations, and express all feature comparisons 
in terms of just four comparison operators 


5. Reduce the hypothesis to canonical disjunctive normal form (a 
disjunction of conjunctions). 


6. For each of the conjunctions, attempt to show that it can be 
satisfied by some feature collection. 


6.1 Separate the feature value tests into independent feature 
groups, such that each group contains tests involving just one 
feature tag. Thus, no predicate in a feature group contains a 
feature tag that also appears in some other group. 


6.2 For each feature group, merge the various constraints to a 
minimum form. This process either yields a reduced expression 
for the allowable range of feature values, or an expression 
containing the value FALSE, which is an indication that no 
combination of feature values can satisfy the constraints (in 
which case the corresponding conjunction can never be 
satisfied). 


7. If the remaining disjunction contains at least one satisfiable 
conjunction, then the constraints are shown to be satisfiable. 


The final expression obtained by this procedure, if it is non-empty, 
can be used as a statement of the resulting feature set for possible 
further matching operations. That is, it can be used as a starting 
point for combining with additional feature set constraint predicate 
to determine a feature set that is constrained by the capabilities of 
several entities in a message transfer path. 
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NOTE: as presented, the feature matching process evaluates (and 
stores) all conjunctions of the disjunctive normal form before 
combining feature tag comparisons and eliminating unsatisfiable 
conjunctions. For low-memory systems an alternative approach is 
possible, in which each normal form conjunction is enumerated and 
evaluated in turn, with only those that are satisfiable being 
retained for further use. 


5.2 Formulating the goal predicate 
A formal statement of the problem we need to solve can be given as: 
given two feature set predicates, '(P x)’ and ’(Q x)’, where ’x’ is 
some feature collection, we wish to establish the truth or otherwise 
of the proposition: 


EXISTS(x) : (P x) AND (O x) 


i.e. does there exist a feature collection 'x' that satisfies both 
predicates, 'P' and 'Q'? 


Then, if feature sets to be matched are described by predicates 'P' 
and 'Q', the problem is to determine if there is any feature set 
satisfying the goal predicate: 

(& P Q) 
i.e. to determine whether the set thus described is non-empty. 


5.3 Replace set expressions 


Replace all "set" instances in the goal predicate with equivalent 
"simple" forms: 


T= [ El, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) 
(T=[R1..R2]) --» (& (T>=R1) (T«-R2) ) 
(T=[E] ) --»  (T-E) 


5.4 Move logical negations inwards 


The goal of this step is to move all logical negations so that they 


are applied directly to feature comparisons. During the following 
step, these logical negations are replaced by alternative comparison 
operators. 


This is achieved by repeated application of the following 
transformation rules: 
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(! (& Al A2 ... Am ) ) --> (| (! A1 ) (! A2 ) (! Am ) ) 
(! (| Al A2 ... Am ) ) --» (& (! A1) (! A2) (! Am ) ) 
CE (A) ) --» A 


The first two rules are extended forms of De Morgan's law, and the 
third is elimination of double negatives. 


5.5 Replace comparisons and logical negations 


The predicates are derived from the syntax described previously, and 
contain primitive value testing functions '-', '«-', ">=", The 
primitive tests have a number of well known properties that are 
exploited to reach a useful conclusion; e.g. 


& (B C) » (A C) 

& (B <= C) => (A <= C) 

These rules form a core body of logic statements against which the 
goal predicate can be evaluated. The form in which these statements 
are expressed is important to realizing an effective predicate 
matching algorithm (i.e. one that doesn't loop or fail to find a 
valid result). The first step in formulating these rules is to 
simplify the framework of primitive predicates. 


The primitive predicates from which feature set definitions are 
constructed are '-', '«-' and '»-'. Observe that, given any pair of 
feature values, the relationship between them must be exactly one of 
the following: 


(LT a b): 'a' is less than 'b'. 

(EQ a b): 'a' is equal to 'b'. 

(GT ab): 'a' is greater than 'b'. 

(NE a b): 'a' is not equal to 'b', and is not less than 


or greater than 'b'. 
(The final case arises when two values are compared for which no 
ordering relationship is defined, and the values are not equal; e.g. 
two unequal string values.) 


These four cases can be captured by a pair of primitive predicates: 


(LE a b): 'a' is less than or equal to ’b’. 
(GE a b): 'a' is greater than or equal to 'b'. 


The four cases described above are prepresented by the following 
combinations of primitive predicate values: 
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(LE a b) (GE a b) | relationship 
TRUE FALSE (LT a b) 
TRUE TRUE (EQ a b) 

FALSE TRUE | (GT a b) 
FALSE FALSE | (NE a b) 


Thus, the original 3 primitive tests can be translated to 
combinations of just LE and GE, reducing the number of additional 
relationships that must be subsequently captured: 


(a <= b) --> (LE a b) 
(a >= b) --> (GE a b) 
(a = b) --» (& (LE a b) (GE ab) ) 


Further, logical negations of the original 3 primitive tests can be 
eliminated by the introduction of 'not-greater' and 'not-less' 


primitives 
(NG ab) == (! (GE ab) ) 
(NL a b) == (! (LE ab) ) 


using the following transformation rules: 


(! (a = b) ) --> (| (NL ab) (NG a b) ) 
(! (a <= b) ) --> (NL a b) 
(! (a >= b) ) --» (NG a b) 


Thus, we have rules to transform all comparisons and logical 
negations into combinations of just 4 relational operators. 


5.6 Conversion to canonical form 
NOTE: Logical negations have been eliminated in the previous step. 


Expand bracketed disjunctions, and flatten bracketed conjunctions and 
disjunctions: 


(& (| A1 A2 ... Am ) Bl 82 ... Bm) 
--» (| (& Al B1 B2 ... Bn ) 
(& A2 B1 B2 ... Bn ) 
(& Am Bl B2 ... Bn ) ) 
(& (& Al A2 ... Am) B1 B2 ... Bn ) 
--» (& Al A2 ... Am B1 B2 ... Bn ) 
(| (| AL A2 ... Am ) B1 B2 2. Bn ) 
--» (| Al A2 ... Am B1 B2 ... Bn ) 
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The result is in "disjunctive normal form", a disjunction of 
conjunctions: 


(| (& S11 S12 12023 
(& S21 S22 ... ) 


(& Sm1 Sm2 ... Smn ) ) 


where the "Sij" elements are simple feature comparison forms 


constructed during the step at section 5.5. Each term within the 
top-level EINEN construct represents a single possible feature set 
that satisfies the goal. Note that the order of entries within the 
top-level Io sae and within each '(&...)', is immaterial. 

From here on, each conjunction '(&...)' is processed separately. 

Only one of these needs to be satisfiable for the original goal to be 
satisfiable. 


(A textbook conversion to clausal form [5,11] uses slightly different 
rules to yield a "conjunctive normal form".) 


5.7 Grouping of feature predicates 


NOTE: Remember that from here on, each conjunction is treated 
separately. 


Each simple feature predicate contains a "left-hand" feature tag and 
a "right-hand" feature value with which it is compared. 


To arrange these into independent groups, simple predicates are 
grouped according to their left hand feature tag ('f'). 


5.8 Merge single-feature constraints 


Within each group, apply the predicate simplification rules given 
below to eliminate redundant single-feature constraints. All 
single-feature predicates are reduced to an equality or range 
constraint on that feature, possibly combined with a number of non- 
equality statements. 


If the constraints on any feature are found to be contradictory (i.e. 
resolved to FALSE according to the applied rules), the containing 
conjunction is not satisfiable and may be discarded. Otherwise, the 
resulting description is a minimal form of that particular 
conjunction of the feature set definition. 
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5.8.1 Rules for simplifying ordered values 


These rules 
between the 


f 


£ 


f 


5.8.2 Rules 


a) (LE f b) 
a) (GE f b) 
a) (NL f b) 
a) (NG f b) 
a) (GE f b) 
a) (NL f b) 
a) (NG f b) 
a) (NL f b) 
a) (NG f b) 
a) (NG f b) 


are applicable where there is 
given values 'a' 


and 'b': 
--» (LE fa), 
(LE f b), 
--» FALSE, 
--» FALSE, 
--» (LE fa), 
(NG f b), 
--» (GE f a), 
(GE f b), 
--> (GE f a) 
(NL f b), 
--» FALSE, 
--> (NL f a), 
(NL f b), 
--» FALSE, 
--» (NG f a), 
(NG f b), 


for simplifying unordered values 


These rules are applicable where there is 
applicable to the given values 'a' and 'b 


(LE 
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f 


f 
f 


a) (LE f b) 
a) (GE f b) 
a) (NL f b) 
a) (NG f b) 
a) (GE f b) 
a) (NL f b) 
a) (NG f b) 


--» 


(LE f a), 
FALSE, 
FALSE, 
(LE f a) 
FALSE, 
(LE f a), 
FALSE, 


(GE f a), 
FALSE, 
(GE f a) 
FALSE, 
(GE f a) 
FALSE, 
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a«-b 
otherwise 
a«b 

a«-b 

a«b 
otherwise 


a>=b 
otherwise 
a>b 
otherwise 
a>=b 


a>=b 
otherwise 
a>=b 


a<=b 
otherwise 


a=b 
otherwise 
a!=b 

a!=b 
otherwise 
a!=b 
otherwise 


a=b 
otherwise 
a!=b 
otherwise 
a!=b 
otherwise 
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an ordering relationship 


no ordering relationship 
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(NL f a) (NL f b) --> (NL f a), a=b 
(NL f a) (NG f b) --> (NL f a), a=b 
(NG f a) (NG f b) --> (NG f a), a=b 


6. Other features and issues 
6.1 Named and auxiliary predicates 
Named and auxiliary predicates can serve two purposes: 
(a) making complex predicates easier to write and understand, and 


(b) providing a possible basis for naming and registering feature 
sets. 


6.1.1 Defining a named predicate 


A named predicate definition has the following form: 


named-pred = "(" fname *pname ")" ";-" filter 
fname = ftag ; Feature predicate name 
pname = token ; Formal parameter name 


'fname' is the name of the predicate. 


'pname' is the name of a formal parameter which may appear in the 
predicate body, and which is replaced by some supplied value when the 
predicate is invoked. 


'filter' is the predicate body. It may contain references to the 
formal parameters, and may also contain references to feature tags 
and other values defined in the environment in which the predicate is 
invoked. References to formal parameters may appear anywhere where a 
reference to a feature tag ('ftag') is permitted by the syntax for ' 
filter’. 


The only specific mechanism defined by this memo for introducing a 
named predicate into a feature set definition is the "auxiliary 
predicate" described later. Specific negotiating protocols or other 
specifications may define other mechanisms. 


NOTE: There has been some suggestion of creating a registry for 
feature sets as well as individual feature values. Such a 
registry might be used to introduce named predicates corresponding 
to these feature sets into the environment of a capability 
assertion. Further discussion of this idea is beyond the scope of 
this memo. 
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6.1.2 Invoking named predicates 


Assuming a named predicate has been introduced into the environment 
of some other predicate, it can be invoked by a filter 'ext-pred' of 


the form: 
ext-pred = fname *param 
param = expr 


The number of parameters must match the definition of the named 
predicate that is invoked. 


6.1.3 Auxiliary predicates in a filter 


A auxiliary predicate is attached to a filter definition by the 
following extension to the "filter" syntax: 

filter =/ "(" filtercomp *( ";" parameter ) ")" 
"where" 1*( named-pred ) "end" 


The named predicates introduced by "named-pred" are visible from the 
body of the "filtercomp" of the filter to which they are attached, 
but are not visible from each other. They all have access to the 
same environment as "filter", plus their own formal parameters. 
(Normal scoping rules apply: a formal parameter with the same name as 
a value in the environment of "filter" effectively hides the 
environment value from the body of the predicate to which it 
applies.) 


NOTE: Recursive predicates are not permitted. The scoping rules 
should ensure this. 


6.1.4 Feature matching with named predicates 


The preceding procedures can be extended to deal with named 
predicates simply by instantiating (i.e. substituting) the predicates 
wherever they are invoked, before performing the conversion to 
disjunctive normal form. In the absence of recursive predicates, 
this procedure is guaranteed to terminate. 


When substituting the body of a precdicate at its point of 
invocation, instances of formal parameters within the predicate body 
must be replaced by the corresponding actual parameter from the point 
of invocation. 


Klyne Standards Track [Page 25] 


RFC 2533 A Syntax for Describing Media Feature Sets March 1999 


6.1.5 Example 


This example restates that given in section 4.3 using an auxiliary 
predicate named 'Res': 


(| (& (Pix-x-1024) (Pix-y=768) (Res Res-x Res-y) ) 


(& (Pix-x-800) (Pix-y=600) (Res Res-x Res-y) );q=0.9 
(& (Pix-x=640) (Pix-y=480) (Res Res-x Res-y) );q=0.8 ) 
where 
(Res Res-x Res-y) :- 
(| (& (Res-x-150) (Res-y-150) ) 
(& (Res-x-150) (Res-y=300) ) 
(& (Res-x-300) (Res-y=300) ) 
(& (Res-x-300) (Res-y=600) ) 
(& (Res-x-600) (Res-y=600) ) ) 


end 


Note that the formal parameters of "Res", "Res-x" and "Res-y", 
prevent the body of the named predicate from referencing similarly- 
named feature values. 


6.2 Unit designations 


In some exceptional cases, there may be differing conventions for the 
units of measurement of a given feature. For example, resolution is 
commonly expressed as dots per inch (dpi) or dots per centimetre 
(dpcm) in different applications (e.g. printing vs faxing). 


In such cases, a unit designator may be appended to a feature value 
according to the conventions indicated below (see also [3]). These 
considerations apply only to features with numeric values. 


Every feature tag has a standard unit of measurement. Any expression 
of a feature value that uses this unit is given without a unit 
designation -- this is the normal case. When the feature value is 
expressed in some other unit, a unit designator is appended to the 
numeric feature value. 


The registration of a feature tag indicates the standard unit of 
measurement for a feature, and also any alternate units and 
corresponding unit designators that may be used, according to RFC 
2506. [3]. 


Thus, if the standard unit of measure for resolution is 'dpcm'/, then 
the feature predicate '(res-200)' would be used to indicate a 
resolution of 200 dots-per-centimetre, and '(res-72dpi)' might be 
used to indicate 72 dots-per-inch. 


Klyne Standards Track [Page 26] 


RFC 2533 A Syntax for Describing Media Feature Sets March 1999 


Unit designators are accommodated by the following extension to the 
feature predicate syntax: 


fvalue =/ number *WSP token 


When performing feature set matching, feature comparisons with and 
without unit designators, or feature comparisons with different unit 
designators, are treated as if they were different features. Thus, 
the feature predicate ’ (res=200)’ would not, in general, fail to 
match with the predicate ’ (res=200dpi)’. 


NOTE: A protocol processor with specific knowledge of the feature 
and units concerned might recognize the relationship between the 
feature predicates in the above example, and fail to match these 
predicates. 


This appears to be a natural behaviour in this simple example, but 
can cause additional complexity in more general cases. 
Accordingly, this is not considered to be required or normal 
behaviour. It is presumed that an application concerned will 
ensure consistent feature processing by adopting a consistent unit 
for any given feature. 


6.3 Unknown feature value data types 


This memo has dealt with feature values that have well-understood 
comparison properties: numbers, with equality, less-than, greater- 
than relationships, and other values with equality relationships 
only. 


Some feature values may have comparison operations that are not 
covered by this framework. For example, strings containing multi- 
part version numbers: "x.y.z". Such feature comparisons are not 
covered by this memo. 


Specific applications may recognize and process feature tags that are 
associated with such values. Future work may define ways to 
introduce new feature value data types in a way that allows them to 
be used by applications that do not contain built-in knowledge of 
their properties. 

7. Examples and additional comments 


7.1 Worked example 


This example considers sending a document to a high-end black-and- 
white fax system with the following receiver capabilities: 
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(& (dpi=[200,300]) 
(grey=2) (color=0) 
(image-coding=[MH,MR]) ) 


Turning to the document itself, assume it is available to the sender 
in three possible formats, A4 high resolution, B4 low resolution and 
A4 high resolution colour, described by: 


(& (dpi=300) 
(grey=2) 
(image-coding=MR) ) 
(& (dpi=200) 
(grey=2) 


(image-coding-[MH,MMR]) ) 


(& (dpi=300) (dpi-xyratio-1) 
(color«-256) 
(image-coding-JPEG) ) 


These three image formats can be combined into a composite capability 
Statement by a logical-OR operation (to describe format-1 OR format-2 
OR format-3): 


(| (& 


( 

( 
(image-coding=MR) ) 
(dpi=200) 

(grey=2) 
(image-coding=[MH,MMR]) ) 
( 
( 
( 


image-coding=JPEG) ) ) 


The composite document description can be matched with the receiver 
capability description by combining the capability descriptions with 
a logical AND operation: 


(& (& (dpi=[200,300]) 
(grey=2) (color=0) 
(image-coding-[MH,MR]) ) 

(| (& (dpi=300) 
grey-2) 
image-coding=MR) ) 
dpi-200) 
grey-2) 
image-coding-[MH,MMR]) ) 
dpi-300) 


( 
( 
(& ( 
( 
( 
( 
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(color<=256) 
(image-coding-JPEG) ) ) ) 


--» Expand value-set notation: 


(& (& (| (dpi=200) (dpi=300) ) 
(grey=2) (color=0) 
(| (image-coding-MH) (image-coding=MR) ) ) 
(| (& (dpi=300) 
(grey=2) 
(image-coding=MR) ) 
(& (dpi=200) 
(grey=2) 
(| (image-coding-MH) (image-coding=MMR) ) ) 
(& (dpi=300) 
(color<=256) 
(image-coding=JPEG) ) ) ) 
--» Flatten nested '(&...)': 
(& (dpi=200) (dpi=300) ) 


(| 
(grey=2) (color=0) 
(| 
(| 


color<=256) 
image-coding-JPEG) ) ) ) 


(image-coding-MH) (image-coding=MR) ) 
(& (dpi=300) 
(grey=2) 
(image-coding=MR) ) 
(& (dpi=200) 
(grey=2) 
(| (image-coding=MH) (image-coding=MMR) ) ) 
(& (dpi=300) 
( 
( 


--» (distribute '(&...)' over inner ’(|...)’): 
(& (| (dpi=200) (dpi=300) ) 
(grey=2) (color=0) 
(| (image-coding-MH) (image-coding=MR) ) 
(| (& (dpi-300) (grey-2) (image-coding-MR) ) 
(& (dpi=200) (grey-2) (image-coding-MH) ) 
(& (dpi=200) (grey=2) (image-coding=MMR) ) 
(& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 
--» continue to distribute '(&...)' over '(|...)', and flattening 
nested '(&...)' and EELA : 


(| (& (dpi=200) (grey=2) (color=0) (image-coding=MH) 
(| (& (dpi=300) (grey-2) (image-coding=MR) ) 
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(& (dpi=200) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=300) (color<=256) 
(dpi=200) (grey=2) (color=0) 
(| (& (dpi=300) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=300) (color<=256) 
(dpi=300) (grey=2) (color=0) 
(| (& (dpi=300) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=300) (color<=256) 
(dpi=300) (grey=2) (color=0) 
(| (& (dpi=300) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=200) (grey=2) 

(& (dpi=300) (color<=256) 


(dpi=200) (grey=2) (color=0) 
(dpi=300) (grey=2) ( 
(dpi=200) (grey=2) (color=0) 
(dpi=300) (grey=2) ( 
(dpi=300) (grey=2) (color=0) 
(dpi=300) (grey=2) ( 
(dpi=300) (grey=2) (color=0) 
(dpi=300) (grey=2) ( 
(dpi=200) (grey=2) (color=0) 
(dpi=200) (grey=2) ( 
(dpi=200) (grey=2) (color=0) 
(dpi=200) (grey=2) ( 
(dpi=300) (grey=2) (color=0) 
(dpi=200) (grey=2) ( 
(dpi=300) (grey=2) (color=0) 
(dpi=200) (grey=2) ( 
(dpi=200) (grey=2) (color=0) 
(dpi=200) (grey=2) ( 
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(dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 
(& (dpi=300) (grey=2) (color=0) (image-coding=MH) 

(dpi=300) (color<=256) (image-coding=JPEG) ) ) ) 
(& (dpi=300) (grey=2) (color=0) (image-coding=MR) 

(dpi=300) (color<=256) (image-coding=JPEG) ) ) 


--» Group terms in each conjunction by feature tag: 


(| (& (dpi=200) (dpi-300) (grey-2) (grey=2) (color=0) 
(image-coding-MH) (image-coding=MR) ) 

(& (dpi-200) (dpi=300) (grey-2) (grey-2) (color=0) 
( ) 


image-coding-MR) (image-coding=MR) 
(etc.) 


(& (dpi=300) (dpi=300) (grey-2) (color=0) (color<=256) 
(image-coding-MR) (image-coding=JPEG) ) ) 


--» Combine feature tag comparisons and eliminate unsatisfiable 
conjunctions: 


(| (& (dpi-300) (grey-2) (color-0) (image-coding-MR) ) 
(& (dpi=200) (grey=2) (color=0) (image-coding=MH) ) ) 


Thus, we see that this combination of sender and receiver options can 
transfer a bi-level image, either at 300dpi using MR coding, or at 
200dpi using MH coding. 


Points to note about the feature matching process: 


o The colour document option is eliminated because the receiver 
cannot handle either colour (indicated by ’ (color=0)’) or JPEG 
coding. 


o The high resolution version of the document with ’ (dpi-300)" 
must be sent using ’ (image-coding=MR)’ because this is the only 
available coding of the image data that the receiver can use 


for high resolution documents. (The available 300dpi document 
codings here are MMR and MH, and the receiver capabilities are 
MH and MR.) 


7.2 A note on feature tag scoping 


This section contains some additional commentary on the 
interpretation of feture set predicates. It does not extend or 
modify what has been described previously. Rather, it attempts to 
clarify an area of possible misunderstanding. 
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The essential fact that needs to be established here is: 


Within a given feature collection, each feature tag may have only 
one value. 


This idea is explained below in the context of using the media 
feature framework to describe the characteristics of transmitted 
image data. 


In this context, we have the requirement that any feature tag value 
must apply to the entire image, and cannot have different values for 
different parts of an image. This is a consequence of the way that 
the framework of feature predicates is used to describe different 
possible images, such as the different images that can be rendered by 
a given recipient. 


This idea is illustrated here using an example of a flawed feature 
set description based on the TIFF image format defined for use by 
Internet fax [13]: 


(& (& (MRC-mode-1) (stripe-size=256) ) 
(| (& (image-coding-JBIG-2-LEVEL) (stripe-size=128) ) 
(image-coding-[MH,MR,MMR]) ) ) 


This example is revealing because the 'stripe-size' attribute is 
applied differently to different attributes on an MRC-formatted data: 
it can be applied to the MRC format as a whole, and it can be applied 
Separately to a JBIG image that may appear as part of the MRC data. 


One might imagine that this example describes a stripe size of 256 
when applied to the MRC image format, and a separate stripe size of 
128 when applied to a JBIG-2-LEVEL coded image within the MRC- 
formatted data. But it doesn’t work that way: the predicates used 
obey the normal laws of Boolean logic, and would be transformed as 
follows: 


--» [flatten nested (&...)]: 
(& (MRC-mode-1) (stripe-size=256) 
(| (& (image-coding-JBIG-2-LEVEL) (stripe-size=128) ) 
(image-coding-[MH,MR,MMR]) ) ) 


--» [Distribute (&...) over (|...)]: 
(| (& (MRC-mode-1) (stripe-size-256) 
(& (image-coding-JBIG-2-LEVEL) (stripe-size-128) ) ) 
(& (MRC-mode-1) (stripe-size=[0..256]) 
(image-coding-[MH,MR,MMR]) ) ) 
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--» [Flatten nested (&...) and group feature tags]: 
(| (& (MRC-mode-1) 
(stripe-size-256) 
(stripe-size-128) 
(image-coding-JBIG-2-LEVEL) ) 
(& (MRC-mode-1) 

(stripe-size-256) 
(image-coding-[MH,MR,MMR]) ) ) 


Examination of this final expression shows that it requires both ” 
stripe-size-128' and 'stripe-size-256' within the same conjunction. 
This is manifestly false, so the entire conjunction must be false, 
reducing the entire predicate expression to: 


(& (MRC-mode-1) 
(stripe-size-256) 
(image-coding-[MH,MR,MMR]) ) ) 


This indicates that no MRC formatted data containing a JBIG-2-LEVEL 
coded image is permitted within the feature set, which is not what 
was intended in this case. 


The only way to avoid this in situations when a given characteristic 
has different constraints in different parts of a resource is to use 
Separate feature tags. In this example, 'MRC-stripe-size' and ' 
JBIG-stripe-size' could be used to capture the intent: 


( (& (image-coding-JBIG-2-LEVEL) (JBIG-stripe-size-128) ) 
(image-coding-[MH,MR,MMR]) ) ) 


(& (& (MRC-mode-1) (MRC-stripe-size=256) ) 


which would reduce to: 

(| (& (MRC-mode-1) 
(MRC-stripe-size-256) 
(JBIG-stripe-size-128) 
(image-coding-JBIG-2-LEVEL) ) 

(& (MRC-mode-1) 
(MRC-stripe-size-256) 
( 


image-coding-[MH,MR,MMR]) ) ) 


The property of the capability description framework explicated above 
is captured by the idea of a "feature collection" which (in this 
context) describes the feature values that apply to a single 
resource. Within a feature collection, each feature tag may have no 
more than one value. 
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The characteristics of an image sender or receiver are described by a 
"Feature set", which is formally a set of feature collections. Here, 
the feature set predicate is applied to some image feature collection 
to determine whether or not it belongs to the set that can be handled 
by an image receiver. 


8. Security Considerations 


Some security considerations for content negotiation are raised in 
[15:25:93 


The following are primary security concerns for capability 
identification mechanisms: 


o Unintentional disclosure of private information through the 
announcement of capabilities or user preferences. 


o Disruption to system operation caused by accidental or 
malicious provision of incorrect capability information. 


o Use of a capability identification mechanism might be used to 
probe a network (e.g. by identifying specific hosts used, and 
exploiting their known weaknesses). 


The most contentious security concerns are raised by mechanisms which 
automatically send capability identification data in response to a 
query from some unknown system. Use of directory services (based on 
LDAP [7], etc.) seem to be less problematic because proper 
authentication mechanisms are available. 


Mechanisms that provide capability information when sending a message 
are less contentious, presumably because some intention can be 
inferred that person whose details are disclosed wishes to 


communicate with the recipient of those details. This does not, 
however, solve problems of spoofed supply of incorrect capability 
information. 


The use of format converting gateways may prove problematic because 
such systems would tend to defeat any message integrity and 
authenticity checking mechanisms that are employed. 
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10. 


Many of the ideas presented derive from the "Transparent Content 
Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4]. 
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where Al Gilman and Koen Holtman were particularly helpful in 
refining the feature set algebra. Ideas for dealing with preferences 
and specific units were suggested by Larry Masinter. 
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